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(57) A method and an apparatus for securely mixing 
and splitting multiple audio data streams and determin- 
ing the order of processing the audio streams. A audio 
server and an audio device driver are in kernel space of 
a given computer system. In one embodiment, the com- 
puter system has a data flow checker and adjuster for 
checking the flow of data into data queues and a setup 
application for connecting the audio server and the au- 
dio device driver. The data flow checker and adjuster 
adjusts the flow of data by sending a message up or 
downstream instructing the up or downstream process- 
es/devices to send more data or stop sending data de- 
pending on how full the data queues are. 
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Description 

The present invention relates to the field of provid- 
ing operating system services for use by audio and vid- 
eo applications. More specifically, the present invention 
is a method and apparatus for mixing and splitting mul- 
tiple independent audio data streams in kernel space, i. 
e. part of an operating system that performs basic func- 
tions such as allocating hardware resources. 

Audio and video applications running on a computer 
(e.g. a workstation, a personal computer "PC, main- 
frame, etc.) often require mixing and splitting of data (e. 
g., audio and/or video) as the data is being input or out- 
put to some type of network device such as an Integrat- 
ed Services Digital Network (ISDN) device. An ISDN de- 
vice is a digital phone network defining B-channels car- 
rying up to 64 Kbps. 

Many mixer and splitter devices are implemented in 
firmware or hardware on a card for a PC. A mixer may 
mix outputs from two specific audio peripheral devices 
and mix inputs on a microphone or some other set of 
peripheral devices. There are also software based mix- 
ers and splitters which are available in Apple Macintosh 
computers, IBM PC's and IBM PC compatibles, Sun Mi- 
crosystem, Inc.'s workstations and in other UNIX based 
machines. More particularly, there is the Audio File (AF) 
system from Digital Equipment Corporation (DEC) of 
Maynard, Massachusetts, and Network Audio System 
(NAS) from Network Computing Devices (NCD), Inc. of 
Mountain View, California, which are both audio servers 
that have mixing capabilities. 

Figure 1 illustrates an exemplary embodiment of 
computer employing a conventional mixer/splitter de- 
vice. Computer 101 includes a storage device 1 03, proc- 
essor (CPU) 105 and audio device 110 coupled through 
bus 107. Audio applications 100, 102 and 104 are cou- 
pled to a software-based mixer and splitter, audio server 
106. Audio server 106 is contained in user space 108 
which the area in the storage device used for execution 
of user programs, and is coupled to audio device 110. 
Audio server 106 takes incoming audio data streams 
from one or more audio applications 1 00, 1 02 and 1 04, 
mixes them together and transmits them to audio device 
1 10. Audio server 1 06 also takes an audio data stream 
coming from the audio device 110, clones the data and 
transmits the data to one or more audio applications 
100, 102 and 104 requesting the data. 

As illustrated in Figure 1, software-based mixing 
and splitting functions in the prior art are performed in 
user space 108 and audio device 106 can only handle 
one audio application at a time. Consequently, an audio 
application has to provide its own mixing and splitting 
functions or depend on audio servers such as NAS and 
AF to provide that functionality via a proprietary API (Ap- 
plication Programming Interface). Further, an audio 
server retains exclusive use of the audio-device, forcing 
audio applications to use a given audio server or not 
have access to the audio device at all. This is a poor 



programming practice since it cannot be assumed that 
a given audio server will be available on another ma- 
chine. 

It is more desirable to have the capability to process 
5 multiple simultaneous audio streams in kernel space 
rather than in user space since this allows multiple audio 
applications to access an audio device and allows back- 
ward compatibility with existing audio applications be- 
cause, among other things, the current Application Pro- 
io gram Interface (API) does not change. The ability to 
write to an existing API allows the splitting and mixing 
operations to be transparent regardless of the audio ap- 
plications from which audio data is being received and 
transmitted for the mixing and splitting operations. 
is Therefore it is desirable to have a method and an 
apparatus for processing multiple simultaneous audio 
streams in kernel space. 

BRIEF SUMMARY OF THE INVENTION 

20 

The present invention provides for processing of 
multiple simultaneous audio streams. Additionally, the 
present invention provides for the mixing and splitting 
capabilities in kernel space rather than in user space of 

25 a system's software environment. This allows for some 
backward compatibility with old applications running au- 
dio and allows for writing to an existing interface. The 
ability to write to an existing interface allows the splitting 
and mixing operations to be transparent regardless of 

30 the audio applications from which audio data is being 
received and transmitted for the splitting and mixing op- 
erations. 

In one embodiment of the invention, a computer has 
a central processing unit (CPU) coupled to a storage de- 

35 vice. The storage device has several audio applications 
contained in user space. An audio server (mixer and/or 
splitter) and an audio device driver are in kernel space. 
The present invention also has a data flow checker and 
adjuster for checking the flow of data into data queues 

40 and a setup application for connecting the audio server 
and the audio device driver. The data flow checker and 
adjuster adjusts the flow of data by sending a message 
upstream or downstream instructing the upstream or 
downstream processes/devices to send more data or 

45 stop sending data depending on how full the data 
queues are. 

BRIEF DESCRIPTION OF THE DRAWINGS 

50 Figure 1 illustrates an exemplary embodiment of a 
conventional mixer/splitter employed in a conventional 
computer. 

Figure 2 illustrates a computer system with an ex- 
emplary implementation of the present invention. 
55 Figure 3 is a flow diagram illustrating the general 

steps followed in the setup application of the present 
invention. 

Figures 4a, 4b and 4c illustrate the mixing function 



3 



EP 0 817 045 A2 



4 



of the audio device driver through the audio server of 
the present invention. 

Figures 5a, 5b and 5c illustrate the splitting function 
of the audio server of the present invention. 

Figure 6 is a flow diagram illustrating how the 
present invention deals with scheduling and when the 
mixer reads additional data. 

Figure 7 is a flow diagram illustrating the general 
steps followed to turn on the present invention's optional 
secure mode to add audio applications. 

Figure B illustrates an exemplary embodiment of the 
present invention with telephony applications transmit- 
ting and reading data to and from an I SDN device driver. 

Figure 9 illustrates an exemplary embodiment of the 
present invention for a general desktop use. 

DETAILED DESCRIPTION OF THE INVENTION 

A method and an apparatus tor allowing multiple au- 
dio-video applications and/or audio-video devices to ac- 
cess and utilize an audio server are disclosed. 

Figure 2 illustrates a computer 200 with an exem- 
plary implementation of the present invention. Compu- 
ter 200 has CPU 202 coupled to memory device 204 
through bus 203. Memory device 204 has a plurality of 
audio applications 21 5 1 : 21 5 2 ,. .. , 21 5 N contained in user 
space 208. Audio server (e.g. mixer and/or splitter) 212 
and audio device driver 214 are contained in kernel 
space 210. The audio server 212 includes a data flow 
checker and adjuster 21 3 which monitors the flow of da- 
ta to and from data queues 217, a setup application 21 9 
for adding audio applications 215 1t 21 5 2 ,..., 21 5 N to the 
mixer/splitter operations of audio server 21 2, and secu- 
rity application 221 for providing an optional secure 
mode preventing unauthorized audio applications from 
being added to the mixer/splitter operations of audio 
server 21 2. Data flow checker and adjuster 21 3 adjusts 
the flow of data by sending a message upstream or 
downstream instructing the upstream or downstream 
processes/devices to send more data or stop sending 
data depending on the current capacity of the data 
queues 217. The use of data streams in processing of 
audio data is well known in the art. 

A more detailed description of setup application 21 9 
is presented in the text accompanying Figure 3. Addi- 
tionally, a more detailed description of data flow checker 
and adjuster 21 3 is presented in the text accompanying 
Figure 6. 

Audio applications 21 5, , 21 5 2 21 5 N transmit audio 

data to audio server 212 which in turn mixes the audio 
data and transmits the audio data to audio device 216 
coupled to memory 204 via bus 218 through audio de- 
vice driver 214. Audio device driver 214 is a software 
program which enables computer 200 to communicate 
with the audio device 216 which typically is a micro- 
phone, a speaker or any other device capable of accept- 
ing/outputling audio data. Audio server 21 2 may also be 
utilised when audio device 216 transmits information to 



audio applications 21 5, , 215 2 ,..215 N through audio de- 
vice driver 214. Examples of audio applications 215 1( 
215 2 ,...215 N include, but are not limited to, Sun Micro- 
systems, Inc.'s AUDIOTOOL™, AUDI OP LAY™ and 
5 AUDIORECORD™. An example of audio device driver 
214 includes, but are not limited to : Sun Microsystems, 
Inc.'s a combination audio/dual basic rate interface 
(DBRI ) device driver allowing applications to access au- 
dio and integrated services digital network (ISDN) func- 
10 tionality on SBUS equipped machines. 

CPU 202 includes circuits that control the interpre- 
tation and the execution of instructions which carry out 
the mixing and splitting operations performed by audio 
server 212 and the transmission of data between audio 
is applications 215 1t 215 2 ,...215 N and audio device 216 
through audio device driver 214. Although not shown, 
computer 200 may also include a number of peripheral 
devices including a display device. 

Figure 3 is a flow diagram illustrating the general 
20 steps followed by the setup application of the present 
invention. In step 301 , setup application opens audio de- 
vice driver and acquires a file descriptor associated with 
the audio device driver. In step 302, application opens 
audio server 21 2 and acquires another file descriptor to 
25 identify the audio server. At this point, setup application 
21 9 has two open file descriptors and the audio server 
is not yet involved with the audio device driver. In step 
303, setup application executes an input/output control 
command to add audio applications to the operations 
30 performed by the audio server. 

Audio servers support multiple I/O ports. In initiating 
processing of a second application, the audio server is 
opened as was done in step 301 . A separate unique file 
descriptor is obtained by the setup application from an 
35 operating system which controls execution of the audio 
applications for the second application. The second au- 
dio server port which has been opened is added to the 
mix of the audio server providing for two ports. This proc- 
ess can be repeated to support N audio server ports. 
40 Additionally, a security application provides for an 
optional secure mode when adding additional audio ap- 
plications to an audio mix. More specifically, when the 
secure mode is turned on, the security application turns 
away unauthorized audio applications requesting to be 
45 added to the audio mix. A more detailed description of 
the secure mode is illustrated in Figure 7 and the ac- 
companying text. 

Figures 4a - 4c illustrate how packets of information 
are transmitted from the plurality of audio applications 
so. 215 n 215 2 215 N to audio server 212 which, in turn, are 
mixed and transmitted to audio device driver 21 4. Figure 
4a illustrates the process at time 0. Audio data is typi- 
cally transmitted in packets 500 from the plurality of au- 
dio applications 215 v 215 2 ,...215 N to an audio device 
55 driver 214. In the illustration, audio packets are illustrat- 
ed as boxes labeled P lP ..., P n . An arbitrary number of 
packets are transmitted down data streams on data 
queues 217. The packets may be of arbitrary size. 
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Audio server 212 schedules a timer which activates 
audio server 212 to begin processing data and monitor 
data queues 21 7 to determine if there are any data pack- 
ets in data queues 217. If there are data packets in data 
queues 217. then audio server 21 2 takes a certain por- 
tion of the data packets and sends that portion "down- 
stream" to audio device driver 214 after the data has 
been mixed. 

If audio server 21 2 is activated too often (e.g. to be- 
gin processing data), then the queues may not fill fast 
enough with data packets 500, resulting in inefficient 
use of central processing unit (CPU) resources. If audio 
server 21 2 is not activated often enough, the data pack- 
ets pile up in the data queues and the packets are not 
transmitted "downstream 11 at a fast enough rate to pro- 
duce smooth audio output, introducing latency and pos- 
sible breakup in the transmitted audio. The present in- 
vention utilizes a unique method of determining when to 
read data off the queues, mix it and send it "down- 
stream" lo audio device driver 214. The present inven- 
tion's method assures that data is transmitted in a con- 
tinuous stream. This method is described further in Fig- 
ure 6. 

At time 1 in Figure 4b, audio server 212 strips the 
packets of information off data queues 217. The packets 
retrieved are mixed to produce mixed packet M v More 
specifically, M, represents the sound that would be ob- 
tained if the three packets of data P v P 2 and P 3 are 
mixed together. At time 2 in Figure 4c, audio server 212 
transmits packet M 1 down to audio device driver 214. At 
the same lime, audio server 212 has already read the 
next set of packets P 4 , P 5 and P 6 off of data queues Q1 , 
Q2 and Q3 217 and the process is repeated. 

Figures 5a, 5b and 5c illustrate the splitting (e.g. 
cloning) function of audio server 212 of the present in- 
vention. In Figure 5a, speech recognition process 502 
and Dual Tone Multi Frequency (DTMF, e.g. touch tone) 
detection process application 504 read data transmitted 
from ISDN (Integrated Services Digital Network) device 
driver 506. Packets P^ P 2 and P 3 are transmitted up- 
stream from ISDN device driver 506 at time 0. 

As illustrated in Figure 5b, audio server 212 reads 
packet 1 as sent upstream by ISDN device driver 506 
and duplicates or clones the packet into packets S n and 
S 2 . At time 2, as illustrated in Figure 5c, packets Si and 
S2 are transmitted "upstream" to speech recognition 
process application 502 and DTMF detection process 
application 504 respectively Audio server 212 contin- 
ues to lead packets being sent upstream from ISDN de- 
vice driver 506 and continues cloning the packets for 
delivery to the telephony applications. 

As with the mixing function of the audio server 212, 
data must not be read too fast or too slowly. For exam- 
ple, if audio server 212 is not reading packets coming 
upstream from ISDN device driver 506 fast enough, then 
ISDN device driver 506 may shut itself down and stop 
I/O due to flow control. In a worst case scenario, if ISDN 
device driver 506 does not shut itself down, then it will 
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continue to output packets upstream. Consequently, te- 
lephony applications 502 and 504 will not be able to read 
all the packets in a timely fashion causing additional la- 
tency, e.g. delay, from when the packets were sent by 

5 ISDN device driver 506 and received by telephony ap- 
plications 502 and 504. On the other hand, if audio serv- 
er 212 attempts to read packets too quickly, then the 
packets will not arrive in time to be read causing ineffi- 
cient use of CPU resources. 

to For example, if telephony applications 502 and 504 
stop accepting data, audio server 212 will have no idea 
that telephony applications 502 and 504 have stopped 
and will continue to send data upstream. Eventually, da- 
ta queues 21 7 upstream will fill up and audio server 21 2 

is recognizes that data queues 21 7 are filled. At this point, 
the present invention causes a message to be sent 
downstream to the audio device driver or ISDN device 
driver 506 asking them to stop sending any more addi- 
tional packets. In an alternate embodiment, any addi- 

20 tjonal data which are transmitted from the audio or ISDN 
device driver 506 are discarded. 

The present invention also converts "A-law", "u.- 
law w and "linear Pulse Code Modulation" (PCM) audio 
data as it is transmitted back and forth between the au- 

2S dio applications and the audio device driver A-law, u.- 
law and linear PCM are digital representation of an an- 
alog audio signal, typically sampled at approximately 8 
KHz. For every sample, the amplitude of the audio signal 
is assigned (quantized) a digital value. For these three 

30 encodings, the values used to represent the amplitude 
is a number between zero and +/ - 1 27. More detail may 
be found in the ITU (International Telecommunication 
Union) standard G.711, published 1988. 

The present invention, in order to minimize the time 

35 necessary to convert between the digitized value and 
its amplitude, uses a pre-computed table of amplitude 
values for each encoding which can be indexed with the 
digitized value. Since audio applications identify what 
encoding they will use when they invoke audio server 

40 212, audio server 212 can transparently convert the A- 
law, |j-law and linear PCM data at the time the mix func- 
tion is called within audio server 212. 

Figure 6 is a flow diagram illustrating the general 
steps followed by an embodiment of the data flow check- 

45 er and adjuster of the present invention in scheduling 
the data flow for the mixing operation of the audio server. 
Since the transmission of audio data between the appli- 
cations in user space and the audio device driver in ker- 
nel space are asynchronous, a mechanism must be put 

50 jnto place which determines when audio server 212 is 
to check the lower queues for upstream data coming 
from the audio device and the upper queues for down- 
stream data coming from the audio applications and 
how often it must do so. As mentioned earlier, if audio 

55 server 21 2 checks the queues for data packets too 
quickly, then less than maximum amount of data pack- 
ets will be processed by audio server 212 leading to in- 
efficient use of CPU resources. If audio server 212 
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checks lor data packets in queues too slowly, then data 
packets are not processed last enough and the queues 
may fill up. Once the queues are lull, some data packets 
may be discarded from lack of being read. In the alter- 
native, the audio device may shut itself down if none of 
the data packets are being read. 

In step 601 , if it is time for the data flow checker to 
check the data flow between the audio applications and 
the audio devices, then go to step 602. In step 602, if 
the size of audio data in the output queue is less than 
the maximum size of data to be mixed in each round of 
mixing operations, then go to step 603. In step 603, if 
upper channels do not have enough data in the queue 
for the audio server operation and in step 604. if the size 
of data in the audio device's output queue is greater than 
or equal to a predetermined minimum audio data size 
to be inserted in the audio device output queue (low wa- 
ter mark) 610, then in step 605, the audio server oper- 
ation is performed. In step 611 , data is sent to the output 
queue. Otherwise, in step 606, there is enough audio 
data in the upper channels to fill the output queue up to 
a predetermined minimum ; then in step 607, audio data 
is acquired from the upper channels to fill the output 
queues to the minimum audio data size. If there is not 
enough audio data in the upper channels to fill the output 
queues to a predetermined minimum audio data size, 
then in step 608, the present invention fills up the queue 
with a silent audio signal and sends out a message to 
the appropriate applications to notify them of the under- 
flow condition in step 609 (allowing the process to start 
sending more data downstream). 

Back in step 603, if the size of audio data in the out- 
put queue is less than the maximum and the channel 
has enough audio data in the queue for the audio server 
operation, then in step 610, audio server 21 2 inserts ad- 
ditional audio data in the output queue such that the out- 
put queue contains the maximum size of audio data to 
be mixed in each round of a mixing/splitting operation 
of audio server 212. 

Back in step 602, if the size of data in the audio de- 
vice's output queue is greater than or equal to the max- 
imum size of audio data (in terms of micro seconds) to 
be mixed in each round of mixing operation (high water 
mark), then go to step 612. 

In step 61 2, it is determined whether there are audio 
applications in the mixing operation. If there are none, 
then the process is completed. Otherwise, in step 613, 
the next mixer operation is scheduled and the process 
repeats itself. 

The asynchronisity of data flow is handled similarly 
for the splitting operation of the present invention. . 

Figure 7 is a flow diagram illustrating the general 
steps followed to turn on the optional secure mode of 
the present invention and to add audio applications. In 
step 701, a security application, defined as an applica- 
tion written by the user which runs in user space and 
implements some form of security policy, opens the au- 
dio server and acquires a corresponding file descriptor. 
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In step 702, the security application issues an input/out- 
put command to turn on the secure mode in audio server 
212. 

In step 703, the security application waits for other 

5 audio applications, defined as audio applications written 
by the user which runs in user space and is capable of 
communicating with the security application, to request 
permission to be added to the mix, defined as the current 
mixer/splitter session allowing for audio data sent to and 

io from the audio device to be mixed and distributed to the 
audio applications. 

In step 704, a requesting audio application makes 
a request to join the mix to the security application. If 
the request is not allowed, then the request is ignored 

*s and the security application returns to step 703. If the 
request is allowed, then the security application contin- 
ues to step 705. 

In step 705, security application issues an input/out- 
put command via the file descriptor to allow the request- 

20 ing audio application to be added to the mix. The secu- 
rity application then returns to step 703 to await future 
requests. 

The present invention may be implemented for var- 
ious applications. For example, in Figure 8, multiple te- 

2S lephony applications including telephone record proc- 
ess 800, telephone speech recognition process 502 and 
telephone DTMF (Dual Tone Multi Frequency, such as 
"touch tone") detection process 504 transmit data to IS- 
DN device driver 506 through audio server 212 and read 

30 data from ISDN device driver 506 through audio server 
212. 

Telephone record process application 800 may be 
utilized to record a phone call on the computer. Tele- 
phone speech recognition process 502 may be used to 
35 recognize vocal commands by a user of a computer and 
to respond in accordance to that vocal command, for 
. example, through an Interactive Voice Response (IVR) 
system. Telephone DTMF detection process application 
504 may be utilized to scan for DTMF tone by determin- 
ed ing if a "O" has been pressed or if a M 1 " has been select- 
ed. One or more of these telephony applications may 
have access to the same telephony data through ISDN 
506 and audio server 212. 

In another exemplary embodiment, the present in- 
45 vention may be utilized in a general desktop use. For 
example in Figure 9, desktop 900 may include software 
applications including, but not limited to ShowMe™ TV 
software program 902 and Conloot 904 by Sun Micro- 
systems, Inc. of Mountain View : California. ShowMe™ 
so TV 902 is a computer program which displays television 
(TV) programs on a desktop. ShowMe™ TV 902 re- 
ceives broadcast audio and video data over a network 
displayed on desktop 900 and sends audio data to audio 
device driver 21 4 through audio server 212. 
55 Contool 904 from Sun Microsystems, Inc. of Moun- 
tain View, California, is a software application which is 
designed to monitor various system events on a given 
computer For example, Contool 904 may alert a user 
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upon the occurrence of a certain predetermined event 
on ri computer. To alert the user ol an event, Contool 
904 may enable a flashing message on the display 
screen of the computer or may display some other type 
of prompt to the user. For example, if a user in a network 
is attempting to communicate with another user in the 
network, Contool 904 may enable a prompt to be dis- 
played to the latter user through his/her computer dis- 
play device stating that another user wants to access 
the user. Instead of a visual prompt, Contool 904 may 
also enable an audio prompt to alert the user that an- 
other user in the network would like to access the user. 

Another example use of Contool 904 requiring the 
use of audio device driver 21 4 is when someone is trying 
to log onto another user's workstation causing a security 
breach. Contool 904 may then alert the user ot the se- 
curity breach through, tor example, some type of an au- 
dio prompt. 

In prior art devices, exemplary general desktop ap- 
plications such as ShowMe™ TV 902 may run a contin- 
uous loop of audio stream without the desktop being 
able to stop the audio stream. In such a case, if there is 
some type of a security breach or if a user desired to 
contact the user of desktop 900 through Contool 904, 
that information would bo put on hold until ShowMo™ 
TV 902 has terminated its program. 

The present invention allows processing of multiple 
audio data streams. Hence, with the present invention, 
while ShowMe™ TV 902 is running an application play- 
ing audio data and while Contool 904 is producing oc- 
casional audio prompts to the user at the same time, 
audio server 212 accepts audio data from audio device 
driver 21 2 for both ShowMe™ TV 902 and Contool 904. 

What has been described is a method and an ap- 
paratus for securely processing multiple simultaneous 
audio streams in kernel space. 

While certain exemplary embodiments have been 
described in detail and shown in the accompanying 
drawings, it is to be understood that such embodiments 
are merely illustrative of and not restrictive on the broad 
invention, and that this invention is not to be limited to 
the specific arrangements and constructions shown and 
described, since various other modifications may occur 
to those with ordinary skill in the art. 



Claims 

1 . A method for processing a plurality of data streams 
being transmitted between a memory device and at 
least one audio device coupled to a computer sys- 
tem, the method comprising the steps of: 

processing the plurality of data streams being 
transmitted between at least one application 
running in user space of the memory device 
and the at least one audio device, said process- 
ing being performed by an audio server in ker- 



nel space of the memory device; and 
adjusting flow of data of the plurality of data 
streams between said at least one application 
running in user space and said at least one au- 
5 dio device to prevent data overflow and under- 

flow conditions. 

2. The method of claim 1 wherein said processing step 
further comprises the step of interlacing said at 

10 least one application with said at least one audio 
device through a device driver. 

3. The method of claim 2 further comprising the step 
of acquiring at least one file descriptor for said de- 

*5 vice driver. 

4. The method of claim 1 further comprising the step 
of processing audio data from said at least one ap- 
plication by said audio server. 

20 

5. The method of claim 1 wherein said step of adjust- 
ing further comprises the step of determining 
whether to check data flow between said at least 
one application and said at least one audio device. 

25 

6. The method of claim 5 further comprising the step 
of determining size of audio data in a queue be- 
tween said at least one application and said at least 
one audio device. 

30 

7. The method of claim 6 further comprising the step 
of performing an operation of said audio server if 
said predetermined size of audio data in said queue 
is greater than or equal to a predetermined mini- 

35 mum and less than a predetermined maximum. 

8. The method of claim 5 further comprising the step 
of skipping an operation of said audio server if said 
size of said audio data is greater than or equal to a 

^o predetermined maximum. 

9. The method of claim 6 further comprising the step 
of adding additional audio data if said predeter- 
mined size of said audio data is less than a prede- 

45 termined minimum. 

10. The method of claim 1 further comprising the step 
of preventing an unauthorized application from be- 
ing processed by said audio server. 

50 

11. An apparatus for processing multiple data streams 
between at least one application and at least one 
audio device, including code configured for storage 
on a computer-readable medium and executable by 

55 a computer, the code including a plurality of mod- 
ules each configured to carry out at least one func- 
tion to be executed by the computer, said apparatus 
comprising: 
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an audio server module configured to process 
the multiple data stream in kernel space, said audio 
server module utilizing a data flow checker and ad- 
juster module conligured to adjust data flow be- 
tween the at least one application and the at least S' 
one audio device. 

12. The apparatus of claim 1 1 further comprising a set- 
up module configured to allow data from more than 
one of said at least one application to be approxi- to 
mately simultaneously processed by said audio 
server. 

13. The apparatus of claim 11 further comprising a se- 
curity module configured to prevent data from un- is 
authorized applications from being processed by 
said audio server 

14. A system for processing multiple data streams be- 
tween at least one application and at least one au- 2° 
dio device, including code configured for storage on 

a computer-readable medium and executable by a 
computer, the code including a plurality of modules 
each configured to carry out at least one function to 
be executed by the computer, said system compris- zs 
ing: 

an audio server module configured to process 
the multiple data stream in kernel space, said audio 
server module utilizing a data flow checker and ad- 
juster module configured to adjust data flow be- 30 
tween the at least one application and the at least 
one audio device. 

15. The system of claim 14 further comprising a setup 
module configured to allow data from more than one 35 
of said at least one application to be approximately 
simultaneously processed by said audio server. 

16. The system of claim 14 further comprising a security 
module configured to prevent data from unauthor- 40 
ized applications from being processed by said au- 
dio server. 
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